Individual AppleTalk networks can be connected together as internets. ItΓÇÖs important that your application work across internets; this note contains information on the differences between life on a single AppleTalk, and life on an internet.
You can read about internets (AppleTalk networks connected by one or more bridges) in Inside AppleTalk. What do you need to do about them?
Use a High-Level Network Protocol
Make sure you use the Datagram Delivery Protocol (DDP), or a higher AppleTalk protocol based on DDP, like the AppleTalk Transaction Protocol. Be warned that Link-Access Protocol packets will not make it across bridges to other AppleTalk networks! Also, donΓÇÖt broadcast; broadcast packets will not be forwarded by bridges (broadcasting using protocols above LAP is discouraged, anyway).
Use Name-Binding
As usual, use the Name-Binding Protocol to announce your presence on the network, as well as to find other entities on the network. Pay special attention to zone name fields; the asterisk (as in ΓÇ£MyLaser:LaserWriter:*ΓÇ¥) in a name you LookUp is now important; it means ΓÇ£my zone onlyΓÇ¥ (see the Zone Information Protocol [ZIP] chapter of Inside AppleTalk for information on finding out what other zones exist). The zone field should always be an asterisk when registering a name.
Pay Attention to Network Number Fields
When handling the network addresses returned by NBPLookUp (or anyone else), donΓÇÖt be surprised if the network number field is non-zero (see below for notes on handling of retries in transactions with non-local nodes).
Reconsider the Values YouΓÇÖve Chosen for Retry and Timeout
There are no set rules for choosing values for retry and timeout (under ATP). There are several factors involved. How long will it take this command to execute before the response will be sent? How reliable is the device? Does it have interrupts disabled for periods of time in which packets might get lost? What kind of performance does the user of my application expect?
In general, 10 to 15 seconds is a reasonable timeout value for a command that can be executed immediately (i.e., the responding machine doesnΓÇÖt have to do any processing, and can turn around a response with no delay). This covers a reasonably busy internet where no more than a few ΓÇ£hopsΓÇ¥ (across bridges) might be involved. A network mail application, or one where many half-bridges might be in use, should allow longer timeouts. Of course, most transactions will complete in much less than the allotted time, but longer than 10 or 15 seconds may be too long for a user to wait: (You can also consider handling retries yourself, especially in the case of NBPLookUp calls.)
The ultimate approach would be to dynamically tailor your timeouts, based on current network throughput. When you first contact another network entity, send a test packet and see how long it takes for the other entity to respond (by managing your own NBPLookUp retries, you could even do this as part of your lookup). Base your timeout and retry values on this delay, and dynamically adjust it based on changes in transaction completion speed.
If a transaction fails, try using NBPConfirm to reestablish contact with the other node; if this succeeds, retry the transaction.
Am I Running on an Internet?
The low memory global ABridge is used to keep track of a bridge on the local AppleTalk network (NBP and DDP use this value). If ABridge is non-zero, then youΓÇÖre running on an internet; if itΓÇÖs zero, chances are, youΓÇÖre not (this is not guaranteed, however, due to the fact that the ABridge value is ΓÇ£agedΓÇ¥, and if NBP hasnΓÇÖt heard from the bridge in a long time, the value is cleared).
Watch for Out-Of-Sequence and Non-Exactly-Once Requests
Due to a ΓÇ£raceΓÇ¥ condition on an internet, itΓÇÖs possible for an exactly-once ATP packet to slip through twice; to keep this from happening, send a sequence number as part of the data with each ATP packet; whenever you make a request, bump the sequence number, and never honor an old sequence number.
-- part contents for background part 2
----- text -----
009
-- part contents for background part 7
----- text -----
Will Your AppleTalk Application Support Internets?
